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We, the inventors of the above-identified patent application, namely, Shai Mohaban, Itzhak 
Parnafes, Silvano Gai, and Dinesh Dutt, hereby declare: 

1. We are inventors of the subject matter disclosed and claimed in the above- 
referenced patent application now pending in the United States Patent & Trademark Office 
("Office"), as each of us contributed to the conception of at least one claim in the patent 
application. Any use of the word "our," "we," or "us" in this declaration refers collectively to 
the four named inventors of the patent application, namely Shai Mohaban, Itzhak Parnafes, 
Silvano Gai, and Dinesh Dutt. 

2. We have been informed that the Office has rejected the claims of the application 
as allegedly anticipated by the Network Working Group Internet Draft entitled "RSVP Receiver 
Proxy" by Gai et al ("the Gai reference"), which is attached hereto as Exhibit A . We have read 
the Gai reference. 
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3. The purpose of this declaration is to establish that the contents of the Gai 
reference are derived from our own work. 

4. Prior to October 1999, we conceived of the invention described and claimed in 
this application. Each of us contributed to the conception of at least one claim in the application. 

Shai Mohaban and Itzhak Parnafes were co-founders of a company, Class Data, that was 
acquired by Cisco Systems, Inc. Silvano Gai and Dinesh Dutt were employed by Cisco Systems, 
Inc. at the time that Shai Mohaban and Itzhak Parnafes become employees of Cisco Systems, 
Inc. as a result of the acquisition. Prior to joining Cisco Systems, Inc., Shai Mohaban and Itzhak 
Parnafes were working on an approach for establishing a network resource reservation at a client. 
At the time Shai Mohaban and Itzhak Parnafes become employees of Cisco Systems, Inc., 
Silvano Gai and Dinesh Dutt were working on an approach for establishing a network resource 
reservation at a router. After Shai Mohaban and Itzhak Parnafes become employees of Cisco 
Systems, Inc., Shai Mohaban, Itzhak Parnafes Silvano Gai, and Dinesh Dutt collaborated 
together to develop the subject matter identified by the claims of the patent application. 

5. As a general matter of practice, technology developers often discuss technical 
solutions with their peers. Such discussions are helpful as they often help assess the merit of, 
and gain support for, the technical solution. In this spirit, after we conceived of the invention 
described and claimed in this application, two of the inventors, namely Silvano Gai and Dinesh 
Dutt, discussed the invention as described and claimed in this application with Nitsan Elfassy, 
who was employed by Cisco Systems, Inc. at the time, and Yoram Bernet, who was employed by 
Microsoft Corporation at the time. 

As a result of these discussions, Silvano Gai, Dinesh Dutt, Nitsam Elfassy, and Yoram 
Bernet authored the Gai reference. The purpose of the Gai reference was to present our 
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invention (i.e., the invention that was invented by Shai Mohaban, Itzhak Parnafes, Silvano Gai, 
and Dinesh Dutt) to the Internet community to solicit their comments. 

As it was not necessary to have all of the four inventors author the Gai reference, Shai 
Mohaban and Itzhak Parnafes were not involved in authoring the Gai reference; thus, Shai 
Mohaban and Itzhak Parnafes were not listed as an author of the Gai reference. 

The contributions of Nitsan Elfassy and Yoram Bernet were limited to: (a) discussing 
applications of the invention, after the invention was conceived, with Silvano Gai and Dinesh 
Dutt, and (b) reviewing the Gai reference. Nitsan Elfassy and Yoram Bernet did not contribute 
to the conception of any claim listed in the patent application, and thus, do not qualify as 
inventors of the patent application. However, because of their work in discussing applications of 
the invention and reviewing the Gai reference, it was appropriate to identify Nitsan Elfassy and 
Yoram Bernet as co-authors of the Gai reference. 

As a general matter of practice, it is desirable to list as authors of a Network Working 
Group Internet Draft individuals from more than one organization, since Network Working 
Group Internet Drafts authored by a single organization are given less weight by the technical 
community. In this spirit, Silvano Gai and Dinesh Dutt wished to include Yoram Bernet as a co- 
author of the Gai reference because Internet Drafts are typically presented by representatives of 
at least two organizations. 

6. To the extent that the Gai reference discloses aspects of the invention, those 
aspects of the invention disclosed in the Gai reference either describe our own work, or are 
derived from our own work. Therefore, the Gai reference describes our own work, or derives 
from our own work, as described and claimed in this application. 
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7. The undersigned being warned that willful false statements and the like are 
punishable by fine or imprisonment, or both, under 18 U.S.C. 1001, and that such willful false 
statements and the like may jeopardize the validity of the application or document or any patent 
resulting therefrom, declares that all statements herein made of his/her own knowledge are true, 
and all statements herein made on information and belief are believed to be true. 

> :> ' Signed at ^ kuw&h , this 2J- day of 



SHAI MOHABAN A ^71 



2006. 



Signed at , this day of 



ITZHAK P ARNAFES , 2006. 



Signed at , this day of 



SILVANO GAI , 2006. 



Signed at , this day of 



DINESH DUTT " , 2006. 
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Status of this Memo 

This document is an Internet-Draft and is in full conformance with 
all provisions of Section 10 of RFC2026. 

Internet -Draf ts are working documents of the Internet Engineering 
Task Force (IETF), its areas, and its working groups. Note that other 
groups may also distribute working documents as Internet -Draf ts . 

Internet-Drafts are draft documents valid for a maximum of six months 
and may be updated, replaced, or obsoleted by other documents at any 
time. It is inappropriate to use Internet-Drafts as reference 
material or to cite them other than as "work in progress." 

The list of current Internet -Draf ts can be accessed at 
http://www.ietf.org/ietf/lid-abstracts.txt. The list of Internet- 
Draft Shadow Directories can be accessed at 
http : //www. ietf . org/ shadow. html . 

Distribution of this memo is unlimited. 



Copyright Notice 

Copyright (C) The Internet Society (1998) . All Rights Reserved. 



Gai, Dutt, Elfassy, Bernet [Page 1] 



RSVP Receiver Proxy October 1999 



RSVP has been extended in several directions [Policy] , [Identity] , 
[DCLASS] , [AggrRSVP] , [Dif fModel] , [COPS-RSVP] , These extensions have 
broadened the applicability of RSVP characterizing it as a signaling 
protocol usable outside the IntServ model. 



Abstract 



With the addition of the "Null Service Type" [NullServ] , RSVP is 
being adopted also by mission critical applications that require some 
form of prioritized service, but cannot readily specify their 
resource requirements - These applications do not need to set-up a 
reservation end-to-end, but only to signal to the network their 
policy information [Policy] , [Identity] and obtain in response an 
applicable DSCP [DCLASS] . 

RSVP Receiver Proxy is an extension to the RSVP message processing 
(not to the protocol itself) , mainly designed to operate in 
conjunction with the Null Service Type and with an extension of the 
COPS for RSVP protocol [COPS - RSVP - EXT ] . 
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1. Introduction 

The IETF has come up with two architectures to support QoS in IP 
networks. IntServ (Integrated Services [RFC1633], [RFC2210] ) is an 
architecture that provides the ability for applications to choose 
among multiple, controlled levels of delivery service for their data 
packets. It relies upon explicit signaling by applications to the 
network for the desired QoS. These applications typically know their 
traffic characteristics and have possibly strict latency 
requirements. Such applications require so called "tight QoS" or 
"quantitative QoS". RSVP is the protocol which can be used by 
applications to signal their QoS requirements to the network. 
Applications have to be modified to take advantage of the Integrated 
Services. The receivers control the QoS given to the data stream. 



DiffServ (Differentiated Services, [RFC2474] , [RFC2475] ) is another 
IETF architecture for implementing scalable service differentiation 



in the Internet. There is no explicit signaling protocol used in 
DiffServ. The network is logically divided into edge devices and core 
devices. The edge devices attempt to recognize data flows and assign 
QoS based on this. They also assign a DSCP (DiffServ Code Point) in 
the DS byte of the packets (the byte that used to be called the TOS 
byte) . Core devices use the DSCP to assign a QoS to the microflows. 
Applications typically do not have to be modified to take advantage 
of Differentiated Services. Receivers do not control the QoS given to 
the data stream. 

The recognition of data flows and the assignment of an appropriate 
DSCP is a tricky task and often requires stateful inspection of flows 
and symmetrical routing paths. Moreover, application recognition is 
limited to the information present in the packet traversing the 
network and in "most current network devices is further limited to 
what is in the IP/TCP/UDP headers. Application vendors desire to be 
able to assign QoS to their packets based on both information that 
may not be carried in the packet and information other than the 
IP/TCP/UDP header fields. For example, a SAP print transaction may 
require a different treatment than a SAP database update. Similarly, 
if the user of the application is the CTO of the company, the 
priority assigned to such packets maybe different from that assigned 
to packets of the application being used by some other person in the 
company . 

For this reason RSVP has been proposed also for mission critical 
applications (e.g. ERP) that require some form of prioritized 
service, but cannot readily specify their resource requirements. The 
ISSLL WG is discussing the specification of the Null Service Type as 
a way to use RSVP with a broader range of applications [NullServ] . 
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Some of these applications have the requirement for the end-to-end 
message processing of RSVP. Others simply need to signal to the 
network their identity [Identity] and some additional policy 
information [Policy] related to the flows and obtaining from the 
network some decisions, e.g. the DSCP to be used [DCLASS] . 

RSVP Receiver Proxy is a proposal that mainly addresses this second 
type of applications, i.e., applications that simply want to. use RSVP 
as a signaling protocol toward the network. For them, the end-to-end 
nature of RSVP is not interesting and often is perceived as a 
disadvantage, since it is characterized by a higher latency. 

The RSVP Receiver Proxy: 

o is an alternate way to process RSVP messages and policy information 
in the switch/routers; 

o it does not require any change to the RSVP protocol; 

o it does require an extension to the COPS for RSVP protocol [C0PS- 
RSVP-EXT] . 

In general, "RSVP Proxy" should be symmetric, i.e., it may be useful 
to have RSVP Sender Proxy as well as RSVP Receiver Proxy. This 
document does not define RSVP Sender Proxy at this stage. If the 
document is accepted by the IETF community, the RSVP Sender Proxy can 



be added in the next version. 



This document defines RSVP Receiver Proxy in association with the 
Null Service Type, but nothing prevents using this feature also in 
association with other service types, e.g. the Controlled Load 
service . 

The following section uses an example in which the Receiver Proxy 
functionality is placed in the first hop switch/router . This is a 
possibility, but it is not a requirement. While designing a network 
the following trade-off should be considered: 

o Proxying closer to the server reduces turn around time. 



6 Proxying further" from the server enables additional downstream 
network elements to benefit from the information carried in the 
signaling messages, and to participate in the response. 

o Proxying anywhere in the network enables the deployment of such 
applications in which only the server is required to signal, but 
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the client may remain unchanged. 

The COPS -RSVP Extension [COPS-RSVP-EXT] should enable the network 
administrator to decide how to make the tradeoffs described above. 

2 . An overview of RSVP Receiver Proxy 

With RSVP Receiver Proxy a switch/router acts as a proxy for the 
receiver, e.g. when it receives an RSVP Path message, it generates an 
RSVP Resv message on behalf of the receiver. 

The generation of the Resv message is done under policy control, the 
switch/ router may be programmed either to classify the packets 
marking them with an appropriate DSCP or to use the DCLASS object 
[DCIiASS] to communicate the classification decision to the host. 

The adoption of RSVP Receiver Proxy do not change the basic model of 
RSVP , i.e.: 

o the handling of data flows is unidirectional. If the application 
data is strictly unidirectional it is sufficient to use RSVP only 
in one direction. In the case of bidirectional data, running RSVP 
only in one direction provides a certain performance benefit, but 
to get the maximum performance benefit it is necessary to use RSVP 
in both directions. 

o The application on the host assumes the host model of RSVP, 
including the extensions proposed in [DiffModel] , [Policy] , 
[Identity] , [NullServ] . 

o The message format and the message types are the same of RSVP, 

including the DCLASS object previously proposed in [DCLASS] and the 
Null Service Type [NullServ] . 




o The switch/router acts as a COPS client [COPS] in communicating 
with the policy server, i.e. it uses RSVP client for COPS [COPS- 



RSVP] . Certain extensions to COPS for RSVP are needed [COPS-RSVP- 
EXT] , see Section 4 . 

o The classification of traffic cannot be more granular than 

microflow (the so called five-tuple) or in the case of IPSEC the 
four-tuple that includes the Parameter Index, or SPI, in place of 
the UDP/TCP-like ports [RFC2207] . 

o There is no special support for subflows (a set of packets inside a 
microflow) . Of course, an application may send different Path 



Gai, Dutt, Elf assy, Bernet [Page 5] 



RSVP Receiver Proxy . October 1999 

messages for the same flow at different times, thus providing a 
support for subflows not overlapping in time. 



3. Detailed description of the message processing 

This sections details some of the message processing of a 
switch/router acting as RSVP Receiver Proxy. The description is 
mainly focused on the two fundamental messages in RSVP, i.e. the 
Path Message and the Resv message. Other messages are discussed in 
Section 4.4. 

Figure 1 depicts a simple network topology (two hosts HI & H2 and 
intermediate routers, R1-R5) that will be used in the explanation. 



Path Message > 

< Resv Message 

+ -4/ + + 

| ps'i. I I psi | 
+ + + + 

/ \ / ■ i 

/ \ /i 
/ \ /i 

+ — -+ + + + + + + + + + + + + 

| Hi | — | Ri ,J---| R2 | ---| R3 | ---| R4 R5...|---| H2 | 

+ + + + + + + + + + + + + + 



HI > Rl > R2 > R3 > R4 > R5 > H2 (Regular 

| RSVP 

v case) 

HI < Rl < R2 < R3 < R4 < R5 > H2 



HI > Rl 

| (RSVP Receiver Proxy) 

v 

HI < Rl 



Hx: Host X 

Ry: Router y 

PSz: Policy Server z 



Figure 1: Possible Message Forwarding Behaviors in RSVP 
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Immediately below the network, the normal RSVP message processing is 
reported. The Path message goes hop-by-hop from HI to H2 . The Resv 
message- uses the reverse path of the Path message and goes from H2 to 
HI. The interaction between the network devices and the policy 
servers is the one specified by COPS for RSVP ( [COPS] , [COPS-RSVP] ) . 

With RSVP Receiver Proxy the propagation of the RSVP Path message is 
terminated in the router acting as a proxy, ftny router in the network 
may act as RSVP Receiver Proxy, but it is a good design guideline to 
place the proxy functionality as close as possible to the sender. In 
our case Rl acts as a proxy for H2 under the control of a policy 
server . 

For example, an application on HI uses RSVP to signal parameters upon 
which to base the decision to assign the QoS for a microflow. The 
example assumes that the information needs to be used only by the 
edge network device and it is not required to propagate this further 
down the network 



A possible sequence of steps consists of: 

o The application on HI indicates to the RSVP subsystem that it is a 
sender and specifies its traffic characteristics. It may specify 
additional parameters . 

o This causes the RSVP subsystem on HI to start transmitting RSVP 
Path messages in accordance with normal RSVP/SBM rules. 

o The first hop switch/ router (Rl) receives this message and it 

communicates with the policy server for a decision on how to treat 
the Path message. It copies all the relevant information contained 
in the Path message to the policy server. 

o The policy server communicates a decision to Rl to not forward the 
Path message, but instead to originate and send a Resv message to 
HI. HI data traffic gets assigned the right DSCP by the 
switch/router as per the policy communicated by the policy server. 
The Resv message may also specify to the host the DSCP and shaping 
information to be associated with the microflow using the DCLASS 
object [DCLASS] . 

o On receiving the Resv message, HI may start marking correctly the 
data traffic accordingly to the DSCP received in the Resv message. 
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' 4 . The role of the policy server 



To implement both RSVP and RSVP Receiver Proxy the policy server 
needs to specify a set of decisions [COPS-RSVP-EXT] which is extended 
compared to COPS-RSVP [COPS-RSVP] . If the decision is to accept the 
Path message, the decision message must specify how the network 
device behaves with respect to each of the following: 

o Forwarding of the Path message; 

o Originating a RSVP Resv message; 

o Processing and possibly Forwarding a RSVP Resv message. 



The decision may also possibly include the QoS specification to be 
associated with the flow identified in the Path message. This 
specification consists of a DSCP and possibly a TSPEC (as specified 
by RSVP [RFC2210]) for policing the traffic. 



4.1 Generation of the Resv message by the Receiver Proxy 

It maybe required that the network device originate a Resv message. 
This is a proxy Resv message in the sense that it is being generated 
by the network device and not by the actual receiver (s) identified in 
the RSVP Path message. The format of a Resv message is as follows 
(see [RFC2205] for details) : 

<Resv Message> : := <Common Header> [ <INTEGRITY> ] 

<SESSION> <RSVP HOP> <TIME_VALUESxDCLASS> 
[ <RESV_CONFIRM> ] [ <SCOPE> ] [ <POLICY_DATA> . . . ] 
< STYLE > <flow descriptor list> 



o The network device puts its IP address and L2 address in the source 
IP and source mac-address fields. Since Resv messages follow Path 
messages, this would constitute a valid Resv message. 

o The SESSION object can be copied from the Path message. 

o The RSVP HOP object can be filled in with the IP address of the 
switch/router generating this Resv message. 
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o The TIME_VALUES object contains the refresh period. See below. 

o The STYLE object is set to Wildcard Filter (WF) style indicating 
that the reservation is to be shared and that the sender is 
wildcarded. Associated with a WF style is a FLOWSPEC object which 
is encoded as specified in [RFC2210] or [NullServ] . 

o The SCOPE and RESV_CONFIRM objects need not be included in the Resv 
message. 



o The POLICY_DATA objects will be as returned by the policy server. 

o The Resv message may also contain the new DCLASS object is 

contained in the COPS decision message. The DCLASS object specifies 
the DSCP to be associated with the microflow for which the Path 
message was received. 

o The Resv messages need to be originated and sent for each of the 
periodically-received Path messages. 



4.2 Communication With the Policy Server 

When a network device establishes the co nne ct ion with the .policy 
server, it sends a COPS Client -Open message for the RSVP client. It 
should indicate in this message whether the network device is capable 
of supporting only the base RSVP message processing or also the 
Receiver Proxy message processing. It can do this with in a 
capability list (that can accommodate also future extensions) . To 
deal with existing clients, if the policy server does not receive a 
capability list, it should assume that it is communicating with a 
legacy RSVP client. The capability list can be included as part of 
the ClientSI object passed in the Client-Open message [COPS-RSVP- 
EXT] . 

On receiving a RSVP Path message, the network device sends a COPS REQ 
message to the policy server. This message will be the standard REQ 
message sent on receiving a RSVP Path message. 

The DEC message returned by the policy server for this REQ message 
must contain the information needed to take the decisions listed in 
Section 4 . 

The DEC message SHOULD also contain a list of DSCP [DCLASS] . 

The DEC message may also contain bandwidth information to be 
associated with the microflow: communicating Shaping/ limiting 
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parameters to the network is a powerful Policy Management tool for 
the PDP/LPDP both for Qualitative and Quantitative services. This 
topic needs further study. 

The network device must also be able to determine if a Path message 
is a refresh or a new one. It must communicate with the policy server 
only for new Path messages or for updated ones. 

In the absence of a policy server or if the connection to the policy 
server is not up, the operation of RSVP Receiver Proxy depends on 
policy configuration local to the network device. For example, the 
network device may have a local configuration that specifies: 

o do not accept new flows; 

o honor existing flows until they time-out. 



4.3 Enhancements To Existing Infrastructure 



o COPS for RSVP will have to be enhanced to support the new format 
for RSVP REQ and DEC message as stated in [COPS-RSVP-EXT] . 

o When SBM is in use, it is possible that a device which does not 
support RSVP Receiver Proxy becomes the DSBM on the first-hop 
segment. This can be prevented by the network administrator by 
configuring the appropriate priority on the device with RSVP 
Receiver Proxy support . 



4.4 Processing of other RSVP messages 

This section details the processing of the protocol messages in RSVP 
other than Path and Resv. Only the differences in the processing from 
classical RSVP is specified. 

o PathTear message is honored and is forwarded or not similar to a 
Path message. The policy server is not contacted on receiving a 
PathTear message. This is consistent with the existing behavior of 
COPS for RSVP [RSVP -COPS] . 

o PathErr messages are treated as in normal RSVP. 
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5. RSVP With Null Service Type 

RSVP protocol can be represented as consisting of two parts: a 
message processing part and a resource allocation & resource 
enforcement part. The following are the minimal requirements for a 
network device to support RSVP Null Service Type: 

o The network device MUST implement the message processing part of 
the RSVP protocol . This includes the ability to receive and 
interpret a raw IP packet or UDP-based RSVP packet. 

o If the network device is a L2 device, it SHOULD implement SBM. 

o The network device SHOULD know how to talk to a policy server using 
COPS. Specifically, the network device SHOULD be able to talk to 
COPS as a RSVP client using the extensions defined in [COPS-RSVP- 
EXT] . 

o The node SHOULD keep the RSVP state so that the following Path 
refresh won't cause a repetitive Path handling. 

o The network device SHOULD be able to generate a Resv message 
periodically in a coherent way with the RSVP soft state 
maintenance . 



o 



In the absence of a connection to the policy server, this network 
device depends on policy configuration local to the network device 
(see Section 4.2) . 



6. Security Considerations 



RSVP messages contain an INTEGRITY object which authenticates the 
originating node and is also used to verify the contents of the 
message. Moreover the RSVP message SHOULD contain an IDENTITY object 
that SHOULD be authenticated. If the policy server does not implement 
any security mechanisms, it SHOULD use a clear text version of the 
user identity. 



7. Intellectual Property Considerations 

The IETF is being notified of intellectual property rights claimed in 

regard to some or all of the specification contained in this 

document. For more information consult the online list of claimed 
rights . 



Gai, Dutt, Elf assy, Bernet 



[Page 11] 



RSVP Receiver Proxy 



October 1999 



8 . References 

[COPS] Boyle, J., Cohen, R . , Durham, D., Herzog, S., Raja, R., 

Sastry, A., "The COPS (Common Open Policy Service) 
Protocol", IETF <draf t-ietf -rap-cops-07 . txt>, August 
1999 . 



[RFC1633] R. Braden, D. Clark, S. Shenker, "Integrated Services in 
the Internet Architecture: an Overview," June 1994. 

[RFC2205] Braden, R., Zhang, L. , Berson, S., Herzog, S., and Jamin, 
S., "Resource Reservation Protocol (RSVP) Version 1 
Functional Specification", IETF RFC 2205, Proposed 
Standard, September 1997. 

[RFC2210] J. Wroclawski, "The Use of RSVP with IETF Integrated 
Services," September 1997. 

[RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of 
the Differentiated Services Field (DS Field) in the IPv4 
and IPv6 Headers," December 1998. 

[RFC2475] S. Blake, D. Black, M . Carlson, E. Davies, Z. Wang, W. 

Weiss, "An Architecture for Differentiated Service," RFC 
2475, December 1998. 

[COPS-RSVP] Jim Boyle, Ron Cohen, David Durham, Shai Herzog, Raju 

Rajan, Arun Sastry, "COPS usage for RSVP, " <draft-ietf- 
rap-cops-rsvp-05 . txt>, June 14, 1999 

[COPS-RSVP-EXT] Nitsan Elf assy, Dinesh Dutt, "COPS Extensions for 
RSVP Receiver Proxy Support"," <draf t-nitsan-cops-rsvp- 
proxy-00 . txt>, October 1999. 

[Policy] Shai Herzog, "RSVP Extensions for Policy Control, 

Internet Draft., < draft -ietf -rap-rsvp-ext-06 . txt> , April 
1999. 



[DiffModel] Y. Bernet, A. Smith, S. Blake, "A Conceptual Model for 



Diffserv Routers," Internet Draft, <draf t-ietf -dif f serv- 
model-00 . txt>, June 1999. 



[Identity] Satyendra Yadav, Raj Yavatkar, Ramesh Pabbati, Peter 

Ford, Tim Moore, Shai Herzog, "Identity Representation 
for RSVP, " Internet-Draft <draf t-ietf -rap-rsvp-identity- 
05.txt>, September 1999. 



Gai, Dutt, Elfassy, Bernet 



[Page 12] 



RSVP Receiver Proxy 



October 1999 



[AggrRSVP] Fred Baker, Carol Iturralde, Francois Le Faucheur,- Bruce 
Davie, "Aggregation of RSVP for IP4 and IP6 
Reservations, " <draf t-ietf -issll-rsvp-aggr-00 . txt>, 
September 1999 

[DCLASS] Bernet, Y . , "Usage and Format of the DCLASS Object With 

RSVP Signaling," <draf t-ietf -issll-dclass-00 . txt >, 
August 1999. 



[NullServ] Yoram Bernet, Andrew Smith, B. Davie, "Specification of 
the Null Service Type," <draf t-ietf -issll-nullservice- 
OO.txt>, September 1999 

[RSVPDIFF] Bernet, R . Yavatkar, P. Ford, F. Baker, L. Zhang, M. 

Speer, B. Braden, B. Davie, J. Wroclawski, E. Felstaine, 
"Integrated Services Operation Over Diffserv Networks," 
<draf t-ietf -issll-diff serv-rsvp-03 . txt>, September 1999 



/ 



Gai, Dutt, Elf assy, Bernet 



[Page 13] 



RSVP Receiver Proxy 



October 1999 



9. Author Information j 
Silvano Gai 

Cisco Systems, Inc. i 

17 0 Tasman Dr. ; 

San Jose, CA 95134-1706 j 

Phone: (408) 527-2690 ! 

email: sgai@cisco.com I 

i 

Dinesh Dutt ! 

Cisco Systems, Inc. j 
170 Tasman Dr. 

San Jose, CA 95134-1706 j 

Phone: (408) 527-0955 I 

email: ddutt@cisco.com ! 



Nitsan Elfassy 

Cisco Systems, Inc. 

Cisco Systems, Inc. 

170 Tasman Dr. 

San Jose, CA 95134-1706 

Phone: +972 9 970 0066 

email: nitsan@cisco.com 

Bernet, Yoram 

Microsoft 

One Microsoft Way, 

Redmond, WA 98052 

Phone: (425) 936-9568 

Emai 1 : yoramb@mi crosof t . com 



* i 



Gai, Dutt, Elfassy, Bernet 



[Page 14] 



RSVP Receiver Proxy 



October 1999 



10. Full Copyright Statement 



Copyright (C) The Internet Society (1997) . All Rights Reserved. 

This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English". 

The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 

This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 



Gai, Dutt, Elfassy, Bernet 



[Page 15] 



